State Machine

State Machine 패턴은 컨트랙트의 생애 주기를 유한한 상태(state)들로 나누고, 각 상태에서 허용하는 행위와 전이(transition) 규칙을 명시적으로 정의하는 패턴이다.[1]

컴퓨터 과학의 유한 상태 기계(FSM) 이론에 기반한다.[2]

컨트랙트는 반드시 하나의 상태에만 존재하며 사전에 정의된 규칙에 따라서만 상태가 변경된다.

스마트 컨트랙트는 배포 후 코드 수정이 불가능하다. 그런데 경매, 에스크로, 거버넌스 등 대부분 온체인 비즈니스 로직은 여러 단계를 순서대로 거치는 생애주기를 가진다.

경매에서 정산이 끝난 뒤 입찰을 넣거나 에스크로에서 입금 전에 물건 수령을 확인하는 것은 허용되면 안 된다.

이러한 "잘못된 시점에 잘못된 함수가 호출되는" 버그는 전통 소프트웨어에서는 패치로 해결할 수 있지만 불변(immutable)한 스마트 컨트랙트에서는 자금 손실로 직결된다.[3]

State Machine 패턴은 이 문제를 해결하기 위해 설계되었다.

이 패턴이 해결하는 핵심 문제는 다음과 같다.

enum Stage {
    Created,
    Bidding,
    Revealing,
    Settled
}
Stage public currentStage = Stage.Created;

내부적으로 uint8로 저장된다. 정의되지 않은 값으로의 캐스팅은 revert된다. (Solidity 0.8+)[4]

modifier atStage(Stage expected) {
    require(currentStage == expected, "Invalid stage");
    _;
}

함수에 atStage(Stage.Bidding)을 붙이면 Bidding 상태에서만 실행된다.

선형 전이 - 순서대로만 진행:

function nextStage() internal {
    currentStage = Stage(uint(currentStage) + 1);
}

명시적 전이 - 허용된 경로만:

function transitionTo(Stage next) internal {
    require(allowedTransitions[currentStage][next]);
    currentStage = next;
}

블록체인에는 cron이 없으므로 다음 트랜잭션 호출 시 시간 경과를 검사한다.[5]

modifier timedTransition() {
    if (currentStage == Stage.Bidding
        && block.timestamp >= createdAt + BIDDING_DURATION)
        currentStage = Stage.Revealing;
    if (currentStage == Stage.Revealing
        && block.timestamp >= createdAt + BIDDING_DURATION + REVEAL_DURATION)
        currentStage = Stage.Settled;
    _;
}

event StageChanged(Stage indexed from, Stage indexed to, address indexed triggeredBy);

모든 상태 전이에서 이벤트를 발행하여 오프체인 추적을 가능하게 한다.

상태가 순차적으로만 진행되는 경우. nextStage()로 uint(currentStage) + 1 계산.

경매, ICO, 투표, 타임락에 적합하다.

분기·복귀가 있는 워크플로우에서 사용한다. 허용된 전이를 mapping으로 정의한다.[1]

mapping(Stage => mapping(Stage => bool)) private allowedTransitions;

constructor() {
    allowedTransitions[Stage.AwaitingPayment][Stage.Funded] = true;
    allowedTransitions[Stage.Funded][Stage.Delivered] = true;
    allowedTransitions[Stage.Funded][Stage.Disputed] = true;
    allowedTransitions[Stage.Disputed][Stage.Delivered] = true;  // resolve
    allowedTransitions[Stage.Disputed][Stage.Cancelled] = true;  // cancel
}

이중 mapping은 검증당 SLOAD 2회가 필요하다. 비트마스크를 사용하면 SLOAD 1회 + 비트 연산으로 줄일 수 있다.[6]

mapping(Stage => uint8) private transitionMap;

// AwaitingPayment -> Funded(bit 1) 허용
transitionMap[Stage.AwaitingPayment] = 1 << uint8(Stage.Funded);

function transitionTo(Stage next) internal {
    require(transitionMap[currentStage] & (1 << uint8(next)) != 0);
    currentStage = next;
}

상태 전이 함수가 외부 컨트랙트에 ETH를 송금하거나 외부 함수를 호출할 때, 호출받은 컨트랙트가 원래 함수를 다시 호출(재진입)할 수 있다. 이때 상태가 아직 변경되지 않았다면, atStage modifier를 통과하여 동일한 함수가 반복 실행된다.[3]

대응은 Checks-Effects-Interactions(CEI) 패턴이다. 상태 변경(Effect)을 외부 호출(Interaction)보다 먼저 수행하면, 재진입 시 이미 변경된 상태에 의해 atStage에서 revert된다.[7]

시간 기반 전이(timedTransition)는 block.timestamp에 의존한다. 블록 제안자는 이 값을 실제 시간 대비 약 15초 범위 내에서 조작할 수 있다.[8] 따라서 각 단계의 최소 길이를 수 분 이상으로 설정해야 한다.

상태 전이를 발생시키는 트랜잭션이 mempool에 공개되면, 공격자가 이를 관찰하고 더 높은 가스비로 자신의 트랜잭션을 먼저 포함시킬 수 있다.[9] 대응으로는 commit-reveal 스킴이나 전이 전 최소 지연 시간을 두는 방법이 있다.